This PR broke nightlies before December 1st 2024. Ideally it would be nice if patch version bumps didn't break old compiler versions, though for nightlies it might be unreasonable to ask. Still @davidhewitt maybe someone should check that this isn't a regression on stable? Or you probably have CI checks for that?

I'm not sure exactly what's going wrong though we should be on the not(ptr_eq) branch...

I'm not sure exactly what's going wrong though we should be on the not(ptr_eq) branch...

It could be an unlucky edge case that you use a nightly from the 1.85 window, before fn_addr_eq was introduced.

Ideally it would be nice if patch version bumps didn't break old compiler versions, though for nightlies it might be unreasonable to ask. Still @davidhewitt maybe someone should check that this isn't a regression on stable? Or you probably have CI checks for that?

True, we try our best to support a wide range or compiler versions, but we can only check so much. Current MSRV is 1.63, which is also checked in CI. So on a stable compiler everything should work.

Yeah that makes sense, can't test unlucky nightly ranges. Thanks @Icxolu!

Well, fn_addr_eq exists in our compiler but it is behind an unstable library feature ptr_fn_addr_eq. rust-lang/rust#133678 made ptr_fn_addr_eq on by default. I'm not sure why the cfg doesn't exactly match the feature.

I'm not sure why the cfg doesn't exactly match the feature.

These are our own cfgs for pyo3 that we use to conditionally enable functions that depend on compilers version. I think the unlucky case here is that fn_addr_eq will stabilize in 1.85, but you are using a nightly of the same version from before the stabilization. It should work correctly for all nightlies after the stabilization and for the 1.85 stable release as well, once that lands.